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Abstract.  The  goal  of  this  paper  is  that  configuration  management  is  a  simple 
and  cost  effective  method  to  secure  the  development  environment  without  im¬ 
peding  innovation,  creativity,  or  schedule.  Software  development  is  a  business, 
and  it  is  reasonable  to  assume  both  developers  and  customers  want  systems 
that  are  protected  because  there  will  always  be  attempts  to  gain  access  to 
software  and  the  data/information  residing  in  the  computer  systems. 

Introduction 

Software  security  is  to  prevent  the  world  from  harming  the 
system,  malicious  or  unintentional,  [1]  and  encompasses  the 
ability  to  prevent,  detect,  and  react  to  malicious  indicators.  Many 
security  analysts  view  external  threat-agents  as  the  primary 
source  of  harm.  However,  the  greatest  risk  to  any  system  is  from 
those  who  are  developing  the  system.  Developers  introduce 
security  exposures  either  maliciously  or  unintentionally  into  the 
system.  Mitigating  these  risks  requires  security  analysis  and  an 
investigation  of  all  vulnerabilities  in  the  Software  Development 
Life  Cycle  (SDLC)  models.  Investigating  the  vulnerabilities  for  all 
of  the  SDLC  models  is  extremely  labor  intensive,  but  there  are 
three  areas  common  to  most  models:  Programming  person¬ 
nel,  Configuration  Management  (CM)  practices,  and  Quality 
Assurance  (QA)  practices.  Each  area  of  the  SLDC  reviewed 
emphasizes  the  difference  between  secure  coding  and  securing 
the  environment  by  reviewing  threat  agents  and  threat  exposure, 
assessing  configuration  management’s  role  in  securing  the 
environment,  and  finally,  discussing  methods  to  monitor  for  mali¬ 
cious  intent  with  lessons  from  Stuxnet  and  the  Heartworm  Bug. 
The  authors  look  at  the  SDLC  from  a  lens  that  strives  to  guide 
software  teams  to  implement  a  comprehensive  security  policy  to 
make  penetration  of  the  system’s  information  security  perimeter 
more  difficult  [2]. 

Programmers  as  Threat  Agents 

Microsoft  reports  more  than  50%  of  the  reported  security 
defects  are  introduced  in  the  design  of  a  component  [3]  and 
this  is  critical  to  looking  at  where  the  threats  exist  and  oppor¬ 
tunities  for  threat  exposure  in  the  in  the  software  development 
environment.  Microsoft’s  finding  suggests  both  designers  and 
programmers  are  threat  agents  in  the  development  environment. 
According  to  Microsoft’s  data,  designers  and  programmers 
introduce  vulnerabilities  into  an  application;  it  is  therefore  ap¬ 
propriate  to  identify  all  of  the  software  developer  roles  (analysts, 
designers,  programmers,  testers)  as  potential  threat-agents. 
Viewing  software  developers  as  threat-agents  should  not  imply 
the  individuals  filling  these  roles  are  careless  or  criminal,  but 


they  have  the  greatest  opportunity  to  introduce  source  code 
compromising  the  systems  confidentiality,  integrity,  or  availability. 
Software  developers  can  expose  assets  accidently,  by  introduc¬ 
ing  a  defect  or  intentionally  through  the  introduction  of  malicious 
functionality.  Defects  have  many  causes,  such  as  oversight  or 
lack  of  experience  with  a  programming  language,  and  are  a 
normal  part  of  the  development  process. 

Development  processes  are  the  activities,  constraints, 
resources,  and  techniques  to  produce  an  intended  output  [4]. 
Software  developers  perform  the  daily  development  activities 
habitually;  they  know  their  jobs,  so  why  question  whether  there 
are  flaws  in  the  development  process?  The  answer  is  that  team 
members  have  their  own  view  of  the  process,  based  on  what  is 
important  to  them  personally.  For  example,  someone’s  financial 
circumstances  may  have  changed  or  other  personal  hardships 
could  result  in  an  angry,  vulnerable,  or  distracted  team  member. 
Many  organizations  conduct  background  checks,  credit  checks, 
and  drug  tests  when  hiring  new  employees  as  part  of  the  com¬ 
pany’s  security  policy,  but  the  company  may  not  perform  periodic 
background  checks.  Developers  need  to  understand  that  as 
organizations  uses  locks  on  their  doors  to  protect  their  physical 
property;  there  is  a  need  to  conduct  periodic  security  screenings 
to  protect  intellectual  property  and  financial  assets  from  those 
with  the  greatest  access.  Although  these  actions  are  intrusive, 
they  serve  to  sustain  a  secure  environment,  provide  stability 
through  structure,  and  reduce  risk. 

During  development  of  a  software  application,  there  are 
many  opportunities  to  introduce  security  exposures.  To  address 
these  exposures,  many  researchers  recommend  enhancing  an 
organization’s  QA  program.  One  frequent  recommendation  is 
expanding  the  inspection  practice  by  introducing  a  checklist  for 
the  various  exposures  provided  by  the  programming  languages 
[3]  [5].  Items  added  to  a  security  inspection  checklist  typically 
include  functions  such  as  Basic’s  Peek  ()  and  Poke  ()  func¬ 
tions,  C’s  string  copy  functions,  exception  handling  routines,  and 
programs  executing  at  a  privileged  level.  Functions  like  Peek() 
and  Poke()  make  it  easier  for  programmers  to  access  memory 
outside  of  the  program,  but  a  character  array  or  table  without 
bounds  checking  produces  similar  results.  A  limitation  of  the 
language  specific  checklist  is  each  language  used  to  develop 
the  application  must  have  a  checklist.  For  some  web  applica¬ 
tions,  this  could  require  three  or  more  inspection  checklists, 
and  this  may  not  provide  safeguards  for  all  the  vulnerabilities. 
Static  analyzers,  such  as  the  Software  Assurance  Metrics  And 
Tool  Evaluation  (SAMATE)  research,  sponsored  by  the  National 
Institute  of  Standards  and  Technology  (NIST),  is  an  approach  to 
automating  some  of  the  objectives  associated  with  an  inspec¬ 
tion  checklist,  but  static  analyzers  have  a  reputation  for  flagging 
source  statements  that  are  not  actually  problems  [6].  Using 
a  rigorous  inspection  process  as  a  safeguard  identifies  many 
defects,  but  does  not  adequately  protect  from  exposures  due 
to  malicious  functionality.  An  inspection  occurring  before  the 
source  code  is  placed  under  configuration  control  provides 
substantial  exposure.  In  this  situation,  the  developer  simply  adds 
the  malicious  functionality  after  the  source  code  passes  the 
inspection  or  provides  the  inspectors  a  listing  without  the  mali¬ 
cious  functionality. 
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SOFTWARE  ENGINEERING  TOOLS  AND  THE  PROCESSES  THEY  SUPPORT 


Figure  1.  Traditional  Unit  Level  Development  Process 


Programming  languages  and  development  processes  offer  a 
number  of  opportunities  to  expose  assets;  but  many  of  the  tools, 
such  as  debuggers  and  integrated  development  environments, 
can  expose  an  asset  to  unauthorized  access.  Many  development 
tools  operate  at  the  same  protection  level  as  the  operating  sys¬ 
tem  kernel  and  function  well  as  a  worm  to  deposit  a  root  kit  or 
other  malicious  software.  Another  potential  exposure,  not  related 
to  programming  languages,  is  testing  with  ‘production  data’. 
Using  ‘production  data’  may  permit  access  to  information  the 
developers  do  not  need  to  know.  Now  that  we  have  addressed 
some  areas  to  apply  QA,  we  will  look  at  the  next  step,  address¬ 
ing  vulnerabilities  and  back  doors. 

Software  developers  address  software  vulnerabilities  by 
loading  the  latest  virus  definitions  and  implementing  all  of  the 
security  guidelines  [7],  but  if  the  environment  is  not  secure,  the 
product  is  still  at  risk  for  back  doors  or  malicious  intent  resulting 
in  security  breaches.  Acknowledging  the  software  development 
environment’s  threat  agents  are  often  the  software  engineers 
is  a  major  step  in  reviewing  security  processes.  There  is  a  ten¬ 
dency  to  focus  on  the  existing  vulnerabilities  and  threats  since 
this  provides  managers  and  customers  a  sense  that  all  security 
bases  are  covered.  The  development  environment  permits  many 
opportunities  to  discover  a  business’s  processes  and,  in  turn, 
their  vulnerabilities,  and  how  we  protect  those  process  leads  to 
our  next  topic,  Configuration  Management. 

Configuration  Management 

One  tool  for  securing  the  environment  is  auditing  through  CM 
so  the  development  team  can  focus  on  building  functionality,  not 
managing  the  change  [8].  Software  CM  (SCM)  is  the  traditional 
technique  for  controlling  the  content  of  deliverable  components 
and  is  an  essential  element  of  a  robust  security  policy  [9]. 

Figure  1  illustrates  a  traditional  unit-level  development  process 
indicating  possible  points  of  vulnerability.  As  illustrated  in  Figure 
1 ,  a  developer  receives  a  change  authorization  to  begin  the 
modification  or  implementation  of  a  software  unit.  Generally,  the 
“authorization”  is  verbal  and  the  only  record  of  the  authorization 
appears  on  a  developer’s  progress  report  or  the  supervisor’s 
project  plan.  To  assure  another  developer  does  not  update  the 
same  source  component,  the  developer  “reserves”  the  necessary 
source  modules.  Next,  the  developer  modifies  the  source  code 
to  have  the  necessary  features.  When  all  of  the  changes  are 
complete,  the  developer  informs  the  supervisor  who  assembles 
a  review  panel  consisting  of  three  to  five  senior  developers  and/ 


or  designers.  The  panel  examines  the  source  code  to  evaluate 
the  logic  and  documentation  in  the  source  code.  A  review  com¬ 
mittee  recommends  the  developer  make  major  changes  to  the 
source  code  that  requires  another  review,  minor  changes  that 
do  not  require  a  full  review,  or  no  changes  are  required.  It  is  at 
this  point  in  the  development  process  where  the  source  code  is 
the  most  vulnerable  to  the  introduction  of  malicious  functionality, 
because  there  are  no  reviews  or  checks  before  the  software  is 
“checked-in.” 

Another  limitation  of  inspections  is  that  the  Agile  method¬ 
ology  recommends  formal  inspections  and  Scrum  uses  pair 
programming  and  testing  based  on  the  Backlog  list  to  deter¬ 
mine  what  functionality  is  priority  for  developer  resources  [5]. 
Using  inspections  as  the  primary  safeguard  from  development 
exposures  limits  the  cost  savings  promised  by  Agile  develop¬ 
ment  methodologies  and  does  not  provide  complete  protection 
from  a  developer  wishing  to  introduce  malicious  software.  Of 
the  six  areas  of  CM,  the  two  areas  having  the  greatest  effect 
on  security  are  configuration  control  and  configuration  audits. 
Version  control  tools,  such  as  Clearcase  and  CVS,  provide  many 
of  the  features  required  by  configuration  control.  Most  version- 
control  systems  permit  anyone  with  authorized  access  to  check 
source  code  “in”  and  “out”  without  an  authorized  change  request 
and  some  do  not  even  track  the  last  access  to  a  source  module. 
However,  in  a  secure  environment,  a  version  control  system 
must  integrate  with  the  defect  tracking  system  and  record  the 
identification  of  the  developers  who  accessed  a  specific  source 
module.  Integrating  the  version  control  system  with  the  defect 
tracking  system  permits  only  the  assigned  developer  to  make  a 
specified  change  and  access  the  related  source  code.  It  is  also 
important  for  the  version  control  system  to  track  the  develop¬ 
ers  who  access  the  code  -  traceability.  Frequently,  developers 
copy  source  code  from  a  tested  component  or  investigate  the 
approach  used  by  another  developer  to  address  a  specific  issue 
in  their  work,  or  need  access  to  read  source  modules  they  are 
not  maintaining.  This  access  provides  an  opportunity  for  insiders 
to  research  and  learn  how  to  introduce  malicious  functionality 
into  another  source  module.  By  logging  source  module  access, 
security  personnel  can  monitor  access  to  the  source  code.  Con¬ 
figuration  audits  are  the  second  management  technique  making 
a  development  organization  more  secure  [10].  Some  regula¬ 
tory  agencies  require  audits  for  safety  critical  applications/ 
high  reliability  applications  to  provide  an  independent  review  of 
the  delivered  product.  An  audit  in  a  high  security  environment 
addresses  the  need  to  assure  the  delivered  product’s  software 
does  not  expose  the  organizational  assets  to  risk  from  either 
defects  or  malicious  functionality.  To  increase  confidence  that 
the  delivered  software  does  not  contain  defects  or  malicious 
functionality,  auditors  should  assure  that  the  test  cases  provided 
1 00%  coverage  of  the  delivered  source  code.  This  is  particu¬ 
larly  important  with  interpreted  programming  languages,  such 
as  Python  or  other  scripting  languages,  because  a  defect  can 
permit  the  entry  of  malicious  code  by  a  remote  use  of  the  soft¬ 
ware.  Auditors  could  adopt  the  approach  of  selectively  re-testing 
configuration  items  with  the  unit-test  data  to  assure  the  results 
from  the  re-test  match  those  produced  in  the  verification  and 
validation  procedure,  and  that  all  of  the  statements  in  the  code 
are  executed. 
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Adopting  the  recommendation  for  a  stronger  CM  process 
modifies  the  typical  unit-level  development  process,  illustrated 
in  Figure  1 ,  to  a  more  secure  process  illustrated  in  Figure  2.  In 
the  more  secure  process  illustrated  in  Figure  2,  a  formal  change 
authorization  is  generated  by  a  defect  tracking  system  or  by  the 
version  control  system’s  secure  change  authorization  function. 
Next,  a  specified  developer  makes  the  changes  required  by 
the  change  authorization.  After  implementing  and  testing  the 
changes,  the  developer  checks  all  of  the  artifacts  (source  code, 
test  drivers,  and  results)  into  the  version  control  system.  Check¬ 
ing  the  artifacts  automatically  triggers  a  configuration  audit  of 
the  developer  artifacts.  Auditors  may  accept  the  developer’s 
changes  or  create  a  new  work  order  for  additional  changes. 
Unlike  the  review  panel,  the  auditors  may  re-test  the  software 
to  assure  adequate  coverage  and  that  the  test  results  match 
those  checked  in  with  the  source  code.  Making  this  change  to 
the  development  process  significantly  reduces  the  exposure  to 
accidental  defects  or  malicious  functionality  because  it  verifies 
the  source  code  deployed  in  the  final  product,  along  with  all 
supporting  documentation. 

CM  should  be  viewed  as  important  to  keeping  the  develop¬ 
ment  team  informed  of  code  changes,  to  include  who  made  the 
code  changes,  and  to  indicate  when  those  code  changes  were 
made  [1 1].  The  goal  is  to  inform  and  challenge  developers  to 
merge  security  and  process  to  prevent  the  introduction  of  mal¬ 
ware  by  threat  agents  through  safeguards  to  strengthen  existing 
processes.  CM  helps  keep  the  cost  of  security  low-cost  with  the 
basics  of  version  control  and  audit.  Management  will  be  pushing 
the  team  to  deliver  and  move  on  to  the  next  project,  software 
developers  need  something  practical  that  provides  structure 
while  not  restricting  innovation  and  creativity  or  impeding  the 
schedule.  CM  should  play  a  major  role  in  securing  the  software 
development  environment  because  it  assists  with  the  discovery 
and  prevention  of  malicious  intent  by  threat  agents,  whether  the 
agents  are  hackers,  malware  coders,  or  insider  threats.  Next,  we 
will  discuss  how  to  establish  QA  in  the  SLDC  and  use  lessons 
from  external  threats  to  emphasize  the  importance  of  QA. 

Quality  Assurance  and  Lessons  from  External  Threats 

Another  element  of  a  robust  development  security  policy  is 
QA  in  the  SLDC  through  the  separation  of  the  development  and 
production  systems.  Developing  software  in  the  production 
environment  exposes  organizational  assets  to  a  number  of 
threats,  such  as  debugging  tools  or  simply  writing  a  program  to 
gain  unauthorized  access  to  information  stored  on  the  system.  A 
worm  implanted  on  computers  or  portable  flash  drives  that 
might  eventually  be  connected  to  the  targeted  network,  such  as 
the  Stuxnet  worm.  The  level  of  sophistication  of  the  Stuxnet 
worm  could  only  come  from  insider  knowledge  of  the  computing 
architecture  and  daily  operations.  Another  important  point  about 
the  Stuxnet  worm  is  that  it  targeted  a  development  tool  and  the 
tool  introduced  the  malicious  functionality.  For  a  secure 
development  environment,  testing  must  not  only  look  at  the 
vulnerabilities  of  the  past,  but  also  conduct  what-if  analysis  for 
all  of  the  tools  and  software  being  used  for  the  project  develop¬ 
ers  have  to  think  like  a  hacker  because  hackers  work  to  reverse 
engineer  an  application  to  make  it  perform  what  they  want. 

Since  Stuxnet  was  engineered  brilliantly  as  described  by 


Figure  2.  Secure  Unit  Development  Process 


personnel  from  Kaspersky  Lab  [1 2],  developers  must  take 
preventive  action.  Code  can  have  a  time  delay  or  malware  can 
remain  dormant,  or  malware  may  be  hidden  in  a  library  or  service 
routine,  all  actions  an  insider  could  insert  for  activation  after  the 
software  is  deployed.  The  Heartbleed  Bug  was  a  software 
defect  developers  closed  in  April  2014  with  a  patch  to  the 
OpenSSL  code  [13].  The  OpenSSL  software  is,  as  the  name 
implies,  open  source,  a  result  of  many  developers  coding 
beginning  in  1 998  using  the  C  programming  language  to  build 
crypto  services.  OpenSSL  is  used  widely  both  on  the  Internet 
and  in  firmware  [13],  further  delaying  the  ability  of  many 
organizations  to  implement  the  patch  across  all  platforms  for  the 
HeartBleed  bug.  There  will  be  damage  from  the  HeartBleed  bug 
because  of  the  types  of  data  possibly  extrapolated  from 
websites,  i.e.  certificates,  user  names  and  passwords,  messages, 
emails,  and  documents.  Using  open  source  code  does  not 
preclude  the  development  team  from  checking  that  the  code 
meets  QA  standards.  Code  must  perform  its  intended  function 
and  not  introduce  security  vulnerabilities.  Identifying  all  of  the 
potential  exposures  and  creating  safeguards  provides  a 
significant  challenge  to  the  security  analysts;  but  by  analyzing 
the  development  process,  it  is  possible  to  identify  a  number  of 
cost  effective  safeguards.  Configuration  management,  pairwise 
coding,  and  vulnerability  checks  are  all  simple  security  safe¬ 
guards  that  could  have  prevented  the  HeartBleed  bug.  Security 
breaches  have  made  the  news  headlines  and  consumed  labor 
hours  for  patches  and  corrective  actions,  a  result  of  attacks  on 
software  services  by  software  developers  who  have  become 
insider  threat  agents.  The  insider  threat  is  real,  whether  it  is  from 
former  employees  who  have  maintained  possession  of  their 
identification  cards  or  contracted  National  Security  Agency 
(NSA)  employees  having  access  levels  exceeding  their  authori¬ 
zation,  the  insider  can  upend  all  of  a  development’s  team  effort. 
Social  engineering  in  the  case  of  Stuxnet  [1 4]  and  other  worms 
prompted  the  government  to  ban  USB  drives,  and  these 
examples  continue  to  prove  that  securing  the  environment  is  the 
only  option.  Give  hackers  a  face;  they  are  thieves  with  an 
objective  to  gain  access  into  a  software  system  for  which  they 
do  not  possess  the  credentials  to  access  or  possess.  Locking 
down  the  environment  means  the  owners  of  the  SDLC  are  a 
step  ahead  of  the  criminals  because  they  employed  QA  for  each 
step  in  the  process.  For  example,  developers  have  to  begin  to 
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and  business  professionals  working  on  the  cutting  edge  of  technology. 

You  don't  have  to  join  the  military  to  protect  our  nation.  Become  a  vital  part  of  NAVAIR, 
and  you'll  have  a  career  with  endless  opportunities.  As  a  civilian  employee  you'll 
enjoy  more  freedom  than  you  thought  possible. 

Discover  more  about  NAVAIR.  Go  to  www.navair.navy.mil. 

Equal  Opportunity  Employer  |  U.S.  Citizenship  Required 


design  tests  beyond  code  issues  and  look  at  routine  service 
calls  to  ensure  the  code  does  not  introduce  a  common  vulner¬ 
ability  for  exploitation  upon  deployment.  Consider  whether 
Bluetooth  is  enabling  cyber  espionage.  Historical  data  from  the 
credit  card  industry  has  proven  Bluetooth  as  a  lucrative 
technology  for  cyber  thieves  and  should  be  monitored  to  ensure 
the  interfaces  do  not  contain  malware.  Programs  should  be 
designed  to  perform  cyber  surveillance  on  the  malware  so 
programs  get  routine  reports  on  data  sent  to  servers  and  service 
routines  -  trends  and  analysis  can  point  to  unusual  activity.  Agile 
takes  advantage  of  the  cross-functional  teams  with  both 
developers  and  testers  to  improve  the  quality  of  the  software 
[15].  This  teaming  could  be  used  in  any  type  of  development 
model  to  encourage  collaboration  and  feedback.  The  feedback 
loop  and  reinforcement  of  using  the  QA  and  CM  processes, 
manual  or  automated,  traces  changes  and  makes  changes 
visible  to  everyone  on  the  team  [8].  Visibility  and  sharing  of 
information  in  the  Agile  Process  make  it  difficult  for  insiders  to 
bypass  the  CM  process  and  could  even  prevent  someone  from 
attempting  espionage.  For  example,  if  a  developer  wanted  to 
add  a  logic  bomb  and  deploy  it  six  months  later,  he  or  she  might 
reconsider  if  they  knew  the  code  would  be  peer  reviewed  [1 6] 

[17].  If  CM  personnel  compare  lines  of  code  from  the  previous 
version  to  a  new  version,  the  records  of  code  submissions  are 
traceable  to  an  individual,  and  this  step  could  curtail  fraudulent 
activity.  Waterfall  and  its  recordkeeping  rigor  remove  the 


anonymity,  but  testing  at  the  end  still  provides 
the  insider  opportunities  to  hide  malicious  code 
during  the  rush  to  meet  the  delivery  schedule. 
So  how  does  the  development  team  know  the 
code  deployed  is  the  code  the  team  wants  to 
deploy?  Adherence  to  code  changes  being 
checked  in  to  CM,  and  verification,  i.e.  testing, 
comparing  the  number  of  lines  of  code  to  the 
tested  lines  of  code  is  critical  to  documenting 
the  software  baseline.  Teams  must  follow  the 
process  and  not  allow  a  programmer  to  check 
in  code  without  an  audit  trail.  Processes 
remove  the  human-in-loop  factor,  i.e.  relation¬ 
ships  between  the  developer  and  the  CM  Lead, 
ensuring  processes  apply  to  everyone.  The 
process  requires  buy-in  at  all  levels  because 
security  is  the  responsibility  of  the  development 
team.  Accountability  in  the  software  develop¬ 
ment  environment  maintains  the  integrity  of  the 
software.  If  developers  follow  the  CM  process, 
then  there  is  traceability.  Development  teams 
must  not  forfeit  traceability  and  take  shortcuts 
-  the  process  is  there  to  help  protect  the 
product.  Not  following  the  process  opens  the 
software  development  environment  to  vulner¬ 
abilities.  Statistics  from  the  Computer  Emer¬ 
gency  Response  Team/Coordination  Center 
(CERT/CC)  indicates  well-known  vulnerabili¬ 
ties  are  responsible  for  75%  of  the  security 
breaches;  leaving  25%  a  secure  development 
model  will  not  address  [12].  It  sounds  simple, 
map  to  known  vulnerabilities  to  improve  your  design  and  let  this 
become  a  new  model  to  assist  the  testers,  QA  teams,  and 
automated  tools.  Shirazi’s  proposal  lists  25  common  vulnerabili¬ 
ties,  such  as  buffer  overflow,  integer  overflow,  command 
injection,  SQL  injection,  cross-site  scripting,  and  illegal  pointer 
values,  along  with  countermeasures  to  avoid  the  vulnerabilities 

[18] .  Many  developers  could  view  this  model  as  too  prescriptive, 
because  it  assumes  if  most  programmers  followed  basic  secure 
programming  principles,  then  the  environment  would  be  locked 
down.  Some  would  also  view  this  model  as  useful  to  train 
inexperienced  developers  or  to  standardize  knowledge  across 
the  organization.  Any  list  can  become  a  useful  checklist,  but  a 
model  is  a  process  that  can  be  repeated  to  impose  consistency 
on  the  output.  Consider  how  software  development  teams 
moved  from  Waterfall  to  Agile;  the  process  selected  by  the  team 
depends  on  the  environment  and  business  need.  Additionally, 
change  has  to  be  significant  to  encourage  and  sustain  change 
[14].  Secure  software  development  does  not  require  a  new 
model,  but  the  phases  of  the  existing  models  must  address 
security  and  the  system  architecture  in  the  test  and  QA  phases. 
Another  proposed  secure  software  development  model  is  to 
build  test  tools  based  on  ratios  of  predicted  vulnerabilities  [1 5]. 
Any  model  relying  on  reported  vulnerabilities  or  associations 
attempts  to  predict  future  vulnerabilities  does  provide  indicators 

[19] ,  but  until  the  model’s  variables  are  validated,  caution  must 
be  used.  These  proposals  help  to  code  securely,  but  still  lack  in 
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providing  a  means  to  locking  down  the  software  environment 
[1 4].  While  past  vulnerabilities  do  assist  with  inspection  and 
testing  [16],  [17],  this  is  still  a  reactive  model.  Code  churn  is 
expected  during  development,  but  sound  CM  practices  can 
manage  the  change.  Additionally,  there  are  many  secure 
development  lifecycle  models  (SDL),  for  example,  Microsoft’s 
SDL  is  attempting  to  train  new  developers.  This  makes  the 
development  team  aware  of  the  pitfalls  of  functional  but 
unsecure  software  [20],  but  this  still  does  not  secure  the 
environment,  and  training  does  ensure  the  developers  under¬ 
stand  secure  coding.  Secure  coding  does  not  prevent  malicious 
intent  within  the  environment.  As  one  technology  manager 
stated,  developers’  mistakes  rarely  affect  them  directly  because 
the  defects  are  not  discovered  until  the  operations  phase. 
Correcting  defects  once  software  is  deployed  affects  the 
operations  budget,  not  the  development  budget  [21].  Some 
security  professionals  attempt  to  scare  the  developers  with 
doom  and  gloom  about  security  and  privacy  problems,  as  well  as 
describing  how  best  to  ensure  compliance  to  regulations 
through  secure  coding  [22].  There  should  be  an  emphasis  on 
information  sharing;  inform  the  development  teams  and 
everyone  in  the  company  about  how  much  it  costs  in  operations 
and  marketing  to  clean  up  the  environment  if  malware  is  not 
prevented  [23]  [24].  Steps  such  as  training,  meetings  to  gain 
buy-in,  rewards  to  developers  who  embrace  methods  that 
secure  the  environment,  as  well  as  reprisals  for  those  who  do 
not  adhere  to  doing  their  part  to  secure  the  environment  are 
necessary  to  instill  a  culture  change  so  everyone  values 
securing  the  environment.  Some  notable  examples  of  the  threat 
agent’s  work  were  the  use  of  social  engineering  and  develop¬ 
ment  tools  in  the  case  of  Stuxnet  and  Heartbleed  Bug.  Both 
exploits  resulted  in  havoc  and  further  degraded  the  public’s 
ability  to  trust  the  security  of  software.  Developers  must  take  ac¬ 
tion  by  viewing  the  software  development  environment  as  an 
entity  within  the  SLDC  that  requires  a  rigorous  auditing  method. 
Development  is  the  stage  in  the  SLDC  is  when  the  software  is 
most  vulnerable  to  threat  agents  so  there  has  to  be  a  focus  on 
gaps  in  the  development  process.  The  company  developing 
software  does  not  discharge  its  responsibility  after  its  deploy¬ 
ment;  the  creation,  however  perceived,  remains  a  product  that  is 
company’s  responsibility  until  the  software  is  retired. 

Summary 

Software  development  is  a  business,  and  it  is  reasonable 
to  assume  that  customers  want  systems  that  are  protected 
against  known  vulnerabilities.  The  insider  threat  is  real,  whether 
it  is  from  former  employees  who  have  maintained  possession 
of  their  identification  cards  or  contracted  National  Security 
Agency  (NSA)  employees  having  access  levels  exceeding  their 
authorization,  the  insider  can  upend  all  of  a  development’s  team 
effort.  Social  engineering  in  the  case  of  Stuxnet  [1 4]  and  other 
worms  prompted  the  government  to  ban  USB  drives,  and  these 
examples  continue  to  prove  that  securing  the  environment  is  the 
only  option.  Software  developers  can  address  software  vulner¬ 
abilities,  load  the  latest  virus  definitions,  and  implement  all  of  the 
security  guidelines  [7],  but  if  the  environment  is  not  secured,  the 
product  is  still  at  risk  for  back  doors  and  malicious  intent  that 


lead  to  security  breaches.  Security  breaches  result  in  damages 
to  customer  and  developer  reputation.  Only  a  comprehensive  se¬ 
curity  policy  focusing  on  personnel,  operations  and  configuration 
management  can  provide  the  safeguards  necessary  to  secure 
an  organization’s  assets  from  cyber  risk  factors  [2].  Following  all 
of  these  recommendations  will  not  guarantee  the  security  of  the 
software  development  environment.  There  are  always  new  vul¬ 
nerabilities  and  vulnerabilities  from  social  engineering.  However, 
using  reoccurring  security  checks,  separating  developers  from 
production  systems  and  data,  controlling  media,  training  devel¬ 
opers,  a  culture  of  awareness,  and  rigorous  configuration  man¬ 
agement  practices  should  make  penetration  of  your  information 
security  perimeter  more  difficult.  It  is  also  necessary  to  conduct 
a  periodic  review  of  development  tools  and  configuration  man¬ 
agement  practices,  as  well  as  a  review  of  the  security  standards 
because  threat  agents  will  adapt  to  any  safeguard  that  does 
not  adapt  to  new  technology.  It  makes  good  business  sense  to 
allocate  resources  proportionately  across  the  development  and 
maintenance  phases  to  prevent  malicious  intent,  versus  stopping 
the  current  work  and  re-directing  work  to  address  malicious 
intent.  Technology  changes,  customers’  business  changes,  the 
market  changes,  and  management  changes  are  all  drivers  that 
will  influence  and  determine  how  the  customer  will  assess  the 
quality  of  the  final  software  product. 

Although  this  paper  does  not  strive  to  develop  any  new  meth¬ 
odologies,  models,  processes,  or  test  tools,  each  area  reviewed 
in  the  SLDC  emphasized  the  difference  between  secure  coding 
and  securing  the  environment  with  a  focus  on  the  effectiveness 
and  simplicity  of  Configuration  Management  in  keeping  the  cost 
of  security  low-cost  with  the  basics  of  version  control,  quality 
assurance,  and  auditing.  Any  security  policy  focusing  on  one  as¬ 
pect  of  the  process  will  not  succeed  -  the  software  development 
environment  is  complex,  encompassing  people,  systems,  and 
software.  Since  management  will  be  pushing  the  team  to  deliver 
and  move  on  to  the  next  project,  software  developers  need 
something  practical  that  provides  structure  while  not  restricting 
innovation  and  creativity  or  impeding  the  schedule.  In  that  vein, 
the  authors  of  this  paper  hope  to  have  contributed.  ^ 
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